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FOREWORD 

The  National  Computer  Security  Center  has  established  a  Technical  Guideline 
Program  to  provide  insight  into  the  Trusted  Computer  Systems  Evaluation  Criteria 
(TCSEC)  and  to  assure  that  each  feature  of  the  TCSEC  will  be  discussed  in  detail  and 
provide  the  proper  interpretation  with  specific  guidance.  A  Guide  to  Understanding 
Trusted  Facility  Management  is  the  latest  in  the  series  of  technical  guidelines  that  is 
being  published  This  technical  guideline  has  been  written  to  help  the  computer 
security  manufacturers,  system  evaluators,  and  accreditors,  as  well  as  end  users, 
understand  what  procedures,  methods,  and  processes  are  required  for  trusted 
facility  management  at  B2  through  A1  classes  of  the  TCSEC. 


Information  derived  from  the  requirements  of  the  TCSEC  is  prefaced  by  the  word 
"shall"  and  recommendationsderived  from  good  practices  are  prefaced  by  the  word 
"should  The  recommendations  are  not  to  be  construed  as  supplementary 
requirements  to  the  TCSEC,  since  the  TCSEC  is  the  only  metric  against  which  systems 
are  to  be  evaluated 


We  use  examples,  illustrations,  or  citations  of  administrative  roles  and  operations  in 
the  guideline.  These  examples  are  based  solely  on  their  availability  in  the  computer 
security  literature.  Examples  in  this  document  are  only  to  provide  clarification  and 
are  suggestions  of  appropriate  implementations. 

As  the  Director,  National  Computer  Security  Center,  I  invite  your  recommendations 
for  revision  to  this  technical  guideline.  We  plan  to  review  this  document  when  the 
need  arises. 


7^ 

Patrick  R. 

Director 

National  Computer  Security  Center 


18  October  1989 
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FIGURES 


Figure  1 .  Required  Class  B2  Separation  of  Functions,  Privileges, 
and  Databases 

Figure  2.  Required  Class  B2  and  Class  B3  Separation  of  Functions, 
Privileges,  and  Databases  of  Administrative  Roles 


Figure  3.  Recommended  Separation  of  Functions,  Privileges, 
and  Databases  of  Administrative  Roles 


Figure  4.  Relationships  Among  Administrative  Roles 


1.  INTRODUCTION 


The  principal  goal  of  the  National  Computer  Security  Center  is  to  encourage  the 
widespread  availability  of  trusted  computer  systems.  In  support  of  that  goal  a  metric 
was  created,  the  DoD  Trusted  Computer  System  Evaluation  Criteria  (TCSEC),  against 
which  computer  systems  could  be  evaluated  for  security.  The  TCSEC  was  originally 
published  on  15  August  1983  as  CSC-STD-001-83.  In  December  1985  the  DoD 
adopted  it,  with  a  few  changes,  as  a  DoD  Standard,  DoD  5200.28-STD.  DoD  Directive 
5200.28,  "Security  Requirements  for  Automated  Information  Systems  (AISs)",  has 
been  written,  among  other  reasons,  to  require  that  the  Department  of  Defense 
Trusted  Computer  System  Evaluation  Criteria  be  used  throughout  the  DoD.  The 
TCSEC  is  the  standard  used  for  evaluating  the  effectiveness  of  security  controls  built 
into  AISs.  The  TCSEC  is  divided  into  four  divisions:  D,  C,  B,  and  A,  ordered  in  a 
hierarchical  manner  with  the  highest  division  (A)  being  reserved  for  systems  provid¬ 
ing  the  best  available  level  of  assurance.  Within  divisions  C  ,  B,  and  A,  there  are 
subdivisions  known  as  classes,  which  are  also  ordered  in  a  hierarchical  manner  to 
represent  different  levels  of  security. 

1.1.  PURPOSE 

An  important  assurance  requirement  of  the  TCSEC,  which  appears  in  all  classes  from 
B2  to  A1,  is  trusted  facility  management.  This  refers  to  the  administrative  pro¬ 
cedures,  roles,  functions  (e.g.,  commands,  programs,  interfaces),  privileges  and 
databases  that  are  used  for  secure  system  configuration,  administration  and  opera¬ 
tion. 

The  objective  of  trusted  facility  management  is  to  support  security  and 
accountability  policies  throughout  a  system's  operation.  To  accomplish  this  goal, 
two  key  requirements  are  the  separation  between  Administrator  and  Operator  func¬ 
tions,  in  class  B2,  and  between  security-relevant  and  non-security-relevant  functions 
of  System  Administrators,  in  class  B3.  This  separation  of  administrative  and  operator 
functions,  and  security-relevant  and  non-security-relevant  functions  of  System 
Administrators,  also  applies  to  class  A1 .  These  separations  help  ensure  that  security- 
adverse  effects  of  human  error,  misdeed,  and  system  failure  do  not  affect  adminis¬ 
trative  functions  and  data. 
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The  purpose  of  A  Guide  to  Understanding  Trusted  Facility  Management  is  to  provide 
guidance  to  manufacturers  on  how  to  incorporate  functions  of  trusted  facility  man¬ 
agement  into  their  systems;  to  system  evaluators  and  accreditors  on  how  to  evaluate 
the  design  and  implementation  of  trusted  facility  management  functions;  and  to 
end  users  on  how  to  use  these  functions  effectively,  e  g.,  on  how  to  avoid  common 
pitfalls  of  system  management. 

1.2.  SCOPE 

The  guidelines  for  trusted  facility  management  presented  herein  refer  to  the  separa¬ 
tion  of  administrative  functions,  interfaces,  and  procedures  of  an  important 
assurance  requirement  of  classes  B2  through  A1  of  the  TCSEC.  This  guideline  is 
intended  to  present  the  issues  involved  in  the  design  of  trusted  facility  management. 

This  guideline  contains  five  additional  sections.  Section  2  contains  a  brief  overview 
of  the  inherent  vulnerabilities  of  administrative  roles.  Section  3  presents  TCSEC 
requirements  that  affect  the  design  and  implementation  of  trusted  facility  manage¬ 
ment  functions,  and  includes  recommendations  corresponding  to  each  evaluation 
class.  Section  4  reviews  the  major  requirements  of  trusted  facility  management  as 
stated  in  the  TCSEC.  Section  5  presents  the  separation  between  Administrator's  and 
Operator's  functions  and  the  possible  partitioning  of  the  security-relevant  functions 
of  the  Administrator  and  Operator  into  separate  roles,  functions  and  databases.  Sec¬ 
tion  6  discusses  the  impact  of  the  other  TCSEC  requirements  on  trusted  facility  man¬ 
agement,  including  design  and  modeling  alternatives  for  trusted  facility  manage¬ 
ment. 

Not  addressed  herein  are  personnel  security  measures,  physical  security  of  the  auto¬ 
mated  information  system  equipment,  and  other  administrative  measures  external 
to  the  AIS.  The  evaluation  of  these  measures  is  beyond  the  scope  of  TCSEC-based 
evaluations  [12,  p.  87],  These  guidelines  apply  to  computer  systems,  processing 
environments,  and  products  built  or  modified  with  the  intention  of  satisfying  the 
TCSEC  requirements.  Note  that  this  document  contains  suggestions  and  recom¬ 
mendations  derived  from  TCSEC  objectives  but  which  are  not  required  by  the  TCSEC 
Additional  recommendations  are  made,  which  are  derived  from  the  stated 
objectives  of  the  TCSEC. 
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Recommendations  for  revision  to  this  publication  are  encouraged  and  will  be 
reviewed  periodically  by  the  National  Computer  Security  Center.  Address  all 
proposals  for  revision  through  appropriate  channels  to: 

National  Computer  Security  Center 
9800  Savage  Road 

Fort  George  G.  Meade,  MD  20755-6000 

Attention:  Chief,  Criteria  and  Technical  Guidelines 
Division 


1.3.  CONTROL  OBJECTIVES 

Trusted  facility  management  is  one  of  the  areas  of  operational  assurance.  As  such, 
the  trusted  facility  management  is  an  aspect  of  the  objective,  "assurance."  The 
assurance  objective  provided  in  the  TCSEC  [1 1,  p.  63]  is: 

" Systems  that  are  used  to  process  classified  or  other  sensitive  information 
must  be  designed  to  guarantee  correct  and  accurate  interpretation  of  the 
security  policy  and  must  not  distort  the  intent  of  that  policy.  Assurance  must 
be  provided  that  correct  implementation  and  operation  of  the  policy  exists 
throughout  the  system's  life  cycle. " 

This  objective  affects  trusted  facility  management  in  two  important  ways.  First, 
administrative  roles  of  the  system  are  the  key  components  that  help  to  ensure  the 
enforcement  of  the  system  security  policy,  and  thus,  their  function  must  support  the 
intent  of  that  policy.  Second,  the  administrative  roles  must  satisfy  the  life-cycle 
assurance  requirements  of  correct  implementation  and  operation. 


2.  SECURITY  ADMINISTRATION  -THE  PROBLEM 


Weaknesses  of  trusted  facility  management  are  of  two  kinds:  role-specific  and 
common  to  all  administrative  roles.  Careful  examination  of  both  common 
administrative  roles  and  role-specific  weaknesses  is  important  for  both  system 
designers  and  administrators  because  exposure  to  some  of  these  weaknesses  can  be 
reduced  or  eliminated  by  specific  designs  or  by  administrative  procedure  external  to 
the  system  in  use.  The  distinction  between  the  two  types  of  weaknesses  is  also  useful 
for  the  strengthening  of  mechanisms  and  procedures  supporting  different  roles 
selectively. 

The  weaknesses  discussed  below  are  generic  in  the  sense  that  they  are  not  specific  to 
any  particular  system  or  design.  Careful  analysis  should  be  performed  in  designing 
and  implementing  specific  systems  to  identify  specific  additional  weaknesses  and 
their  required  countermeasures.  Design,  implementation,  and  use  of  automated 
tools  for  analyzing  specific  system  weaknesses  are  useful,  but  still  a  research  subject 
[1]. 

Three  types  of  weaknesses  affect  all  administrative  roles  to  various  degrees: 

(1)  unauthorized  modification  of  hardware  and  software  system  configura¬ 
tion.  Unauthorized  changes  of  system  configuration,  including  both 
hardware  and  software  changes,  can  take  place  during  all  phases  of  a 
system  life  cycle. 

(2)  penetration  of  a  specific  administrative  role.  Penetration  of  administrative 
roles  by  nonadministrative  users,  or  by  unauthorized  administrative  users, 
is  usually  made  possible  by  flawed,  or  weak,  mechanisms  for  identification 
and  authentication,  TCB  protection,  or  role  separation. 

(3)  misuse  of  administrative  authority.  This  can  arise  from  careless  or 
deliberate  misuse  of  administrative  authority.  Misuse  of  authority  can 
cause  both  TCB  and  user  security  violations  and  therefore  can  lead  to 
extensive  damage. 
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3.  TCSEC  REQUIREMENTS  FOR  TRUSTED  FACILITY  MANAGEMENT 


In  the  TCSEC,  requirements  for  Trusted  Facility  Management  are  for  security  classes 
B2  through  A1.  Classes  Cl  through  B1  do  not  have  any  TCSEC  Trusted  Facility 
Management  requirements. 

3.1.  REQUIREMENTS  FOR  SECURITY  CLASS  B2 


3.1.1.  Security  Policy 

No  Additional  Requirements. 


3.1.2.  Accountability 


All  identification  and  authentication  requirements  of  class  B2,  including  trusted 
path,  shall  apply  to  the  administrative  users  individually. 


All  actions  of  administrative  users  shall  be  auditable  in  accordance  with  the  B2  audit 
requirements. 


3.1.3.  Operational  Assurance 


3. 1.3.1.  System  Architecture 


The  TCB  programs  and  data  structures  implementing  administrative  functions: 

•  must  satisfy  the  modularity  requirements  of  class  B2; 

•  must  satisfy  the  least  privilege  principle; 


•  must  use  logically  distinct  storage  objects  with  separate  attributes  (e  g., 
files,  segments). 


The  interfaces  of  the  administrative  roles  implemented  by  the  TCB  must  be 


completely  defined,  and  all  the  elements  of  the  TCB  implementing 
tive  roles  must  be  identified. 


the  administra- 
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3. 1.3. 2.  Trusted  Facility  Management 


The  TCB  shall  support  separate  Operator  and  Administrator  functions.  The 
Administrator's  functions  include  those  of: 

•  the  Security  Administrator 

•  System  Programmer 

•  the  Auditor 

•  the  Account  Administrator  (whenever  this  role  is  defined  to  be  security¬ 
relevant). 

These  functions  must  be  separated  from  those  of  the  Secure  Operator.  While  the 
Administrator's  functions  may  be  combined  into  one  function,  we  recommend  they 
be  separated  as  described  in  section  5.  The  remaining  functions  include  only  the 
non-security-relevant  functions. 

3.1.4.  Life-Cycle  Assurance 

3. 1.4.1.  Security  Testing 

All  security  testing  requirements  of  class  B2  apply  to  the  TCB  functions  and  interfaces 
implementing  administrative  roles  as  stated. 

3. 1.4.2.  Design  Specification  and  Verification 
Recommendation : 

Descriptive  Top-Level  Specifications  (DTLSs)  of  the  TCB  functions  and  in¬ 
terfaces  implementing  administrative  roles  must  be  maintained  that 
completely  and  accurately  describe  these  functions  and  interfaces  in  terms  of 
exceptions,  error  messages,  and  effects. 
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A  formal  security  and  integrity  model  of  trusted  facility  management  should 
be  used  to  define  the  separation  of  administrative  roles,  functions,  privileges 
and  databases. 

3. 1.4. 3.  Configuration  Management 

All  configuration  management  requirements  of  class  B2  apply  to  the  TCB  functions 
and  interfaces  implementing  administrative  roles  as  stated. 

3.1.5.  Documentation 

3. 1.5.1.  Trusted  Facility  Manual 

A  manual  addressed  to  the  AIS  system  administrator  shall  be  available  that  . 

•  presents  cautions  about  functions  and  privileges  that  should  be  controlled 
when  running  a  secure  facility. 

•  gives  procedures  for  examining  and  maintaining  the  audit  files. 

•  gives  the  detailed  audit  record  structure  for  each  type  of  audit  event. 

•  describes  the  operator  and  administrator  functions  related  to  security,  to 
include  changing  the  security  characteristics  of  a  user. 

•  provides  guidelines  on  the  consistent  and  effective  use  of  the  protection 
features  of  the  system 

•  explains  how  the  protection  features  of  the  system  interact. 

•  shows  how  to  generate  a  new  TCB  securely. 

•  provides  guidelines  on  facility  procedures,  warnings,  and  privileges  that 
need  to  be  controlled  in  order  to  operate  the  facility  in  a  secure  manner. 


•  identifies  the  TCB  modules  that  contain  the  reference  validation 
mechanism. 

•  describes  the  procedures  for  secure  generation  of  a  new  TCB  from  source 
after  modification  of  any  modules  in  the  TCB. 

3. 1.5. 2.  Test  Documentation 

All  test  documentation  requirements  of  class  B2,  except  those  for  covert  channel 
testing,  apply  to  the  TCB  functions  and  interfaces  implementing  administrative  roles 
as  stated. 

3. 1.5. 3.  Design  Documentation 

Documentation  shall  be  available  that  provides  a  description  of: 

•  interfaces  between  the  TCB  modules  implementing  functions  of  the 
administrative  roles; 

•  specific  TCB  protection  mechanisms  used  for  the  separation  of  adminis¬ 
trative  roles; 

•  descriptions  of  the  TCB  modules  implementing  functions  and  interfaces 
of  the  administrative  roles; 

•  how  the  least  privilege  principle  is  supported  by  the  functions  and 
interfaces  of  the  TCB  implementing  administrative  roles; 

•  how  the  actions  of  the  administrative  roles  are  audited. 
Recommendation: 

A  formal  description  of  the  security  and  integrity  policy  model  used 
to  define  the  separation  of  administrative  roles  should  be  available 
and  proven  to  be  sufficient  to  enforce  the  claimed  separation. 


3.2.  REQUIREMENTS  FOR  SECURITY  CLASS  B3 


All  the  requirements  of  Class  B2  are  included  at  this  level.  The  additional  class  B3 
requirements  are  listed  below. 

3.2.1.  Security  Policy 

No  Additional  Requirements. 

3.2.2.  Accountability 

The  trusted-path  requirements  of  class  B3  apply  to  administrative  users. 

The  additional  audit  requirements  of  class  B3  apply  to  the  administrative  users. 

3.2.3.  Operational  Assurance 
3  2.3.1.  System  Architecture 

The  additional  TCB  structuring  requirements  of  class  B3  (i.e.,  significant  use  of 
abstraction,  information  hiding,  and  layering)  apply  to  the  functions  and  interfaces 
of  the  TCB  implementing  administrative  roles. 

3  2.3.2.  Trusted  Facility  Management 

The  security-relevant  administrative  functions  (i.e.,  those  of  the  Security 
Administrator,  System  Programmer,  Auditor  and  the  Secure  Operator's  roles  defined 
above)  must  be  separated  from  the  non-security-relevant  administrative  functions. 

The  security-relevant  administrative  functions  must  be  limited  to  those  that  are 
essential  to  performing  the  security  roles  effectively. 

All  actions  of  security  personnel  (Secure  Administrator  and  Secure  Operator)  must  be 
audited. 
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Recommendations: 


The  functions  of  security  administration  and  personnel  should  distinguish  among 

•  System  Programmer,  Security  Administrator,  Auditor,  and  Secure 
Operator 

•  their  privileges 

•  their  databases. 

Different  levels  of  trust  should  be  established  for  the  following  roles  in  accordance 
with  the  power  and  vulnerability  of  each  role: 

•  System  Programmer  (maintenance  and  diagnostics  mode); 

•  Security  Administrator; 

•  Auditor; 

•  Secure  Operator; 

•  Account  Administrator; 

•  Operator. 

(Note:  The  distinction  between  the  System  Administrators,  Operators,  and  System 
Security  Officers  is  explicitly  made  in  the  audit  requirements  of  the  TCSEC  [11,  p.  16]. 
These  roles  correspond  to  the  Account  Administrator,  Secure/Normal  Operator,  and 
Security  Administrator/Auditor  roles  above.  Also  note  that  these  distinctions  do  not 
require  the  separation  of  security-relevant  and  non-security-relevant  functions  as 
they  are  made  in  the  audit  -  not  trusted  facility  management  -  requirement  area). 


3. 2. 3. 3.  Trusted  Recovery 


The  trusted  recovery  requirement  of  class  B3  applies  to  the  functions  and  interfaces 
of  theTCB  implementing  administrative  roles. 

3.2.4.  Life-Cycle  Assurance 

3. 2. 4.1.  Security  Testing 

All  additional  security  testing  requirements  of  class  B3  apply  to  the  functions  and 
interfaces  of  the  TCB  implementing  administrative  roles. 

3. 2.4.2.  Design  Specification  and  Verification 
Recommendation : 

The  additional  design  specification  and  verification  requirements  of  class  B3  should 
be  applied  to  the  functions  and  interfaces  of  the  TCB  implementing  administrative 
roles. 

3. 2. 4. 3.  Configuration  Management 
No  Additional  Requirements. 

3.2.5.  Documentation 

3. 2. 5.1.  Trusted  Facility  Manual 

The  additional  requirements  shall  include  procedures  to  ensure  that  the  system  is 
initially  started  in  a  secure  state  and  also  procedures  to  resume  secure  system 
operation  after  any  lapse  in  system  operation. 

3. 2. 5.2.  Test  Documentation 
No  Additional  Requirements. 
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3.2. 5.3.  Design  Documentation 


No  Additional  Requirements. 

3.3.  REQUIREMENTS  OF  SECURITY  CLASS  A1 

All  requirements  of  the  security  class  B3  are  included  here.  The  only  additional 
requirements  are  in  the  following  "Life-Cycle  Assurance"  areas: 

3.3.1.  Configuration  Management 

All  additional  configuration  management  requirements  of  class  A1  apply  to  the  TCB 
functions  and  interfaces  implementing  administrative  roles. 

3.3.2.  Trusted  Distribution 

All  trusted  distribution  requirements  of  class  A1  apply  to  the  TCB  functions  and 
interfaces  implementing  administrative  roles. 


4.  SATISFYING  THE  TCSEC  REQUIREMENTS 


The  principal  requirements  of  trusted  facility  management  are: 

•  the  separation  of  Operator  and  Administrator  functions; 

•  the  logical  (or  physical)  separation  of  the  database  information  corre¬ 
sponding  to  those  functions;  and 

•  the  implementation  of  least  privilege  such  that  functions  have  only  the 
minimum  necessary  privileges  to  the  databases. 

4.1.  SEPARATION  OF  ADMINISTRATOR  AND  OPERATOR  FUNCTIONS 

The  separation  of  Administrator  and  Operator  functions  is  a  requirement  of  TCSEC 
class  B2,  which  states: 

"The  TCB  shall  support  separate  Operator  and  Administrator  functions. " 

The  primary  purpose  behind  the  separation  of  the  Operator  and  Administrator  func¬ 
tions  is  to  limit  the  potential  damage  that  untrusted,  or  errant,  code  can  inflict  on 
the  information  the  TCB  uses  to  enforce  the  security  policy.  Through  the  application 
of  the  principle  of  least  privilege  and  the  separation  of  Operator  and  Administrator 
functions  so  that  they  are  prevented  from  executing  untrusted  code,  the  TCB  data 
structures  can  be  protected.  The  principle  of  least  privilege  requires  that  each 
subject  be  granted  the  most  restrictive  set  of  privileges  needed  for  the  specific  task. 
In  the  case  of  the  operator  and  administrator  functions,  the  privileges  need  to  be 
established  at  a  low  level  of  granularity  so  that  the  processes  that  implement  those 
functions  do  not  have  unnecessary  privileges.  This  low  level  of  granularity  provides 
several  important  protections: 

•  it  limits  the  effects  of  errors  on  the  part  of  the  administrator; 

•  it  limits  the  effects  of  incorrect  code  that  implements  the  administrator 
functions; 
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•  it  provides  some  protection  against  malicious  administrators,  in  that 
damage  that  can  be  done  is  strictly  confined  to  the  privileges  defined  for 
that  role.  Some  additional  protection  is  afforded  by  auditing 
administrator  actions.  (This  argument  can  be  extended  to  malicious  code 
that  is  inserted  in  the  administrator  functions.) 

The  TCSEC  recognizes  the  need  to  separate  the  operator  and  administrator  functions 
from  the  normal  user  abilities  to  execute  code.  There  are  several  ways  to  implement 
such  separation.  One  way  is  to  enforce  those  restrictions  on  the  Administrator  and 
Operator  functions.  They  can  only  execute  trusted  code  that  has  been  shown  to 
preserve  the  TCB  data  structures  properly.  This  requires  that  the  people  who 
perform  those  functions  also  have  a  separate  account  that  allows  them  to  be  a 
normal  user.  That  separate  account  would  not  have  any  Operator  or  Administrator 
capabilities.  Whatever  approach  to  separation  is  selected,  it  must  be  shown  to 
restrict  the  Operator  or  Administrators  from  executing  untrusted  code. 

The  separa+on  of  Operator  and  Administrator  functions,  namely  between  the 
commands,  programs,  and  interfaces  implementing  those  functions,  is  important 
because  these  functions  are  used  with  different  privileges,  on  different  system  data. 
Should  these  functions  not  be  separated.  Operators  could  use  commands  that 
include  Administrators’  privileges  and  databases.  This  would  mean  that  all 
Operators  would  need  to  be  trusted  to  the  same  degree  as  that  needed  for 
Administrators.  It  would  also  mean  that  the  principles  of  least  privilege  and  separa¬ 
tion  of  privilege,  which  are  two  of  the  most  important  security  principles  (see 
reference  18  for  a  further  explanation  of  these  principles),  are  violated,  overexpos¬ 
ing  the  system  to  error,  failure,  and  misdeed.  Furthermore,  lack  of  functional 
separation  would  fail  to  confine  the  effects  of  any  function  penetration,  leaving  the 
entire  system  in  a  vulnerable  state. 

In  addition  to  the  separation  of  Administrator  and  Operator  functions,  trusted 
facility  management  should  also  separate  internal  system  databases  which  the 
Operator  and  Administrator  manipulate.  Checks  and  balances  are  necessary  to  avoid 
trusting  too  many  all-powerful  Administrators.  The  identification  of  the  security¬ 
relevant,  internal  system  databases  and  the  correlation  between  each  function  and 
the  corresponding  database  shall  be  carefully  performed  and  documented.  The 
separation  of  Operator's  and  Administrator's  functions  shall  also  lead  to  the 


separation  of  accessible  objects  and  of  access  privileges  to  shared  databases.  This  is 
an  essential  design  requirement  for  the  enforcement  of  the  least  privilege  principle 
within  the  TCB  because  it  helps  identify  and  eliminate  unnecessary  Operator  access 
to  administrator  data.  For  example,  the  Administrator  has  full  access  to  system 
databases  that  need  not  be  fully  accessible  to  the  Operator;  i.e.,  the  Administrator 
has  ReadA/Vrite  privileges  to  some  (shared)  databases,  such  as  the  system  security 
profile,  for  which  the  Operator  only  needs  Read  privileges.  Thus,  the  Write  privilege 
of  the  Operator  to  these  databases  would  be  eliminated.  Also,  because  these 
databases  are  separate,  consistency  checks  may  be  derived  from  the  security-relevant 
databases  of  the  Administrator  and  applied  to  the  security-relevant  functions  of  the 
Operator.  This  would  increase  the  robustness  of  the  administrative  functions  of  the 
system  and,  implicitly,  its  usefulness. 

Figure  1  illustrates  both  the  separation  of  function  and  of  privileges/databases  for 
class  B2.  Note  that,  although  the  functions  of  the  Operator  and  Administrator  are 
completely  separated,  the  Administrator's  privileges  include  those  of  the  Operator 
in  the  sense  that  the  Administrator  can  always  get  access  to  all  Operator  functions, 
databases,  and  privileges.  For  example,  an  Administrator  can  always  log  in  as  an 
Operator  and  perform  Operator  functions.  In  contrast,  the  Operator  cannot  get 
access  to  functions,  databases,  and  privileges  that  are  exclusively  the 
Administrator's.  Note,  this  hierarchical  relationship  of  roles  is  a  functional  hierarchy. 
The  system  could  provide  a  "flat"  set  of  roles,  functions  and  privileges,  and  the 
hierarchy  could  be  managed  administratively. 
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4.1.1.  Security-Relevant  Functions  of  the  System  Administrator 

The  security-relevant  functions  of  the  System  Administrator  include  those  that: 

•  define  and  change  the  user  security  characteristics  and  those  of  the  system 
security  data  (e.g.,  user  identifier,  user’s  group  identifiers,  user/group 
maximum  security  level;  and  the  maximum/minimum  security  level  of  the 
system  data,  the  maximum/minimum  security  level  of  each  file  system). 

•  define  and  change  the  system's  security  characteristics  (e.g.,  security  level 
limits  of  multilevel  channels,  I/O  processors,  communication  lines,  and 
devices;  all  possible  level  changes  of  single  level  devices). 

•  perform  system  programming  functions;  (e.g.,  trusted  system  configura¬ 
tion  in  accordance  with  the  configuration  management  policy,  system 
distribution,  system  installation,  and  TCB  code  maintenance  that  may 
affect  system  configuration,  distribution  and  installation). 

•  perform  audit  functions  (e.g.,  determine  what  events  should  be  audited, 
manage  the  audit  trail,  analyze  the  audit  trail,  produce  audit  reports). 
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4.1.2.  Security-Relevant  Functions  of  the  Operator 


The  security-relevant  functions  of  the  Operator  include  those  that: 


•  enable  and  disable  peripheral  devices,  make  changes  to  the  device 
security  characteristics  within  the  limits  defined  by  the  Administrator 
(e  g.,  the  Operator  sets  the  level  of  a  single-level  device  within  the 
range  defined  by  the  Administrator). 

•  control  the  mounting  of  file  systems  and  load  labeled  disk  packs  and 
tape  reels  on  appropriate  drives. 

•  recover  user  files  following  system  crashes. 


•  handle  printed  output. 


•  perform  maintenance  operations 
tenance  of  TCB  databases. 


on  user  databases  and  routine  main- 


•  boot  up  and  shut  down  the  system. 


4.2.  SEPARATION  OF  SECURITY-  AND  NON-SECURITY-RELEVANT  FUNCTIONS 


The  second  requirement  of  trusted  facility  management  is  to  identify,  audit,  and 
separate  the  security-relevant  functions  of  the  Administrator  from  the  non-security- 
relevant  functions.  The  purpose  of  this  requirement  is  to  prevent  an  Operator  or 
Administrator  from  executing  untrusted  code  using  their  special  privileges  that 
would  enable  that  code  to  corrupt  the  policy  enforcement  data  or  mechanisms.  This 
requirement  is  introduced  in  class  B3,  and  is  stated  in  the  TCSEC  as  follows: 


"The  functions  performed  in  the  role  of  a  Security  Administrator  shall  be  iden¬ 
tified.  The  A/S  administrative  personnel  shall  only  be  able  to  perform  Security 
Administrator  functions  after  taking  a  distinct  auditable  action  to  assume  the 
Security  Administrator  role  on  the  AIS.  Non-security  functions  that  can  be  per¬ 
formed  in  the  Security  Administrator  role  shall  be  limited  strictly  to  those 
essential  to  performing  the  security  role  effectively.” 
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Both  the  Administrator  and  the  Operator  roles  include  security-relevant  functions. 
Security-relevant  functions  include  all  administrative  functions  that  are  used  to 
implement  the  security  and  accountability  policies  supported  by  a  system.  Non-secu¬ 
rity-relevant  functions  are  those  that  cannot  affect  the  implementation  of  security 
and  accountability  policies  supported  by  a  system.  The  separation  of  security¬ 
relevant  and  non-security-relevant  functions  is  important  because  security-relevant- 
functions  need  to  be  trusted  to  a  higher  degree  than  non-security-relevant  ones.  A 
higher  degree  of  trust  implies  that  the  operational  and  life-cycle  assurance  tasks  are 
more  extensive  than  those  necessary  for  functions  of  a  lower  level  of  trust.  Although 
some  non-security-relevant  functions  of  the  Administrator  may  be  functionally  a 
part  of  the  TCB  in  class  B2,  flaws  in  these  functions  should  lead  only  to  potential 
denial-of-service  instances,  but  not  to  security  or  integrity  violations.  In  class  B3, 
essentially  the  non-security-relevant  functions  of  the  Administrator  shall  be  removed 
from  the  TCB.  The  TCSEC  does  permit  the  inclusion  of  non-security-relevant 
functions  that  are  essential  to  performing  the  security  role.  While  the  separation  of 
administrative  functions  is  not  required  below  class  B2,  the  benefits  and  protection  it 
provides  should  be  seriously  considered. 

Figure  2  illustrates  both  the  separation  of  function  and  of  privileges/databases  for 
classes  B2  and  B3.  Note,  also  that  the  functions  of  the  Operator  and  Security 
Administrator  (i.e.,  the  non-security-relevant  role  of  the  Administrator)  are 
completely  separated. 

(Alternative  administrative  procedures  for  systems  that  do  not  support  any  separa¬ 
tion  of  roles  have  been  suggested  [5].  These  procedures  may  be  useful  for  systems  in 
TCSEC  classes  Cl  through  B1.) 

4.3.  IMPACT  OF  OTHER  TCSEC  REQUIREMENTS  ON  TRUSTED  FACILITY  MANAGE¬ 
MENT 

The  third  important  requirement  of  trusted  facility  management  is  the  integration 
of  functions  and  programs  that  implement  administrative  roles  within  the  TCB  in 
such  a  way  that  the  security  policy,  accountability,  assurance,  and  documentation 
requirements  of  specific  TCSEC  classes  are  satisfied.  For  example,  in  a  B3  or  above 
system,  the  design  of  each  function  supporting  a  specific  role  must  ensure  that  the 
programs  executing  that  function  operate  with  the  fewest  privileges  necessary  and 
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that  they  are  designed  to  satisfy  the  abstraction,  information  hiding,  and  layering 
requirements.  Furthermore,  in  a  class  B3  or  above  system,  the  non-security-relevant 
functions  of  Administrators  shall  be  removed  from  the  TCB  because  "significant  sys¬ 
tem  engineering  shall  be  directed  towards  minimizing  the  complexity  of  the  TCB  and 
excluding  from  the  TCB  modules  that  are  not  protection  critical"  [11,  pp.  38f].  Some 
work  environments  require  the  system  to  support  multiple  work  shifts.  Such  a  sys¬ 
tem  design,  allowing  multiple  individuals  to  belong  to  the  same  role,  shall  ensure 
that  these  individuals  are  not  forced  to  share  a  role  password,  such  that 
accountability  on  an  individual  basis  is  lost. 

Most  documentation  requirements  of  the  TCSEC  apply  to  trusted  facility  manage¬ 
ment  as  stated  in  each  evaluation  class.  However,  some  requirements  such  as  those 
that  state  the  need  for  a  Security  Features  User's  Guide  (SFUG)  and  for  covert 
channel  analysis  are  obviously  not  applicable.  The  SFUG  is  relevant  for  all  users. 


whereas  the  Trusted  Facility  Manual  and  Trusted  Facility  Management  Guideline  are 
relevant  only  for  administrative  users.  Also,  since  most  administrative  users  have 
mult, level  access  to  system  and  user  data,  they  must  be  trusted  to  maintain  the 
secrecy  and  classification  of  the  data.  Thus,  administrative  users  must  be  cleared  to 
the  highest  level  of  data  classification.  Furthermore,  all  code  implementing  func¬ 
tions  of  administrative  roles  should  be  scrutinized  to  ensure,  to  the  largest  extent 
possible,  that  it  does  not  contain  any  Trojan  horses  or  trap  doors.  Additional 
requirements  imposed  by  the  TCSEC  of  trusted  facility  management  are  discussed  in 
the  section  entitled,  "TCSEC  Requirements  For  Trusted  Facility  Management." 


5.  SEPARATION  OF  OPERATOR'S  AND  ADMINISTRATOR'S  ROLES 


An  important  aspect  of  trusted  facility  management  is  that  of  partitioning  the 
security-relevant  duties  of  the  Administrators  and  Operators  into  separate  roles.  For 
example,  this  partitioning  could  distinguish  the  security-relevant  roles  of  Security 
Administrator,  System  Programmer,  and  Auditor  -  in  addition  to  the  non-security- 
relevant  role  of  Accounts  Administrator;  and  also  could  distinguish  between  the 
security-relevant  functions  of  the  Operator  (the  Secure  Operator  role)  and  the  non¬ 
security-relevant  ones  (the  Operator  role).  Although  this  further  partitioning  of  the 
Administrator's  duties  is  not  required  by  the  TCSEC,  it  is  suggested : 

(1)  by  the  need  to  differentiate  between  the  skills  required  by  different  secu¬ 
rity-relevant  functions  of  the  Administrator  and  Operator, 

(2)  by  the  need  to  divide  the  power  (e  g.,  privileges)  of  the  all-encompassing 
Administrator  duty  into  multiple  roles  that  incorporate  different  levels  of 
trust, 

(3)  by  the  need  to  avoid  entrusting  all  security-relevant  functions  to  a  single 
role  or  individual.  In  this  partitioning  of  the  Administrator's  duties,  the 
Security  Administrator  role  retains  the  functions  of  defining  and  changing  the 
user  and  the  system  security  profiles. 

The  System  Programmer's  functions  differ  from  those  of  the  Security  Administrator, 
Auditor,  Account  Administrator  and  Operators.  The  System  Programmer's  functions, 
privileges,  and  databases  include  those  of  the  other  roles,  as  the  System  Programmer 
is  the  most  privileged  administrative  user  defined  in  any  system.  In  contrast  with  the 
other  roles,  some  of  the  System  Programmer's  actions  may  not  be  auditable.  This  is 
the  case  because  some  of  the  System  Programmer's  actions  take  place  before  the 
Auditor's  programs  and  databases  are  configured  and  loaded.  Furthermore,  the 
System  Programmer's  maintenance  activities  may  refer  to  the  maintenance/repair  of 
the  TCB,  including  the  other  roles’  interfaces  (e  g.,  commands,  programs),  databases, 
and  privileges.  Whenever  possible,  the  System  Programmer  functions  should  be 
relegated  to  system  maintenance  mode  only  and  should  be  monitored  by  adminis¬ 
trative  procedure.  Whenever  possible,  work  on  TCB  code  should  be  done  on  a 
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developmental  system  rather  than  on  a  system  in  current  use.  The  developmental 
system  may  be  a  physically  separate  system  or  a  system  from  which  user  data,  and  in 
particular  classified  data,  have  been  removed  (e.g.,  by  changing  disk  packs  or 
overwriting  memory)  prior  to  performing  TCB  maintenance.  Note  that  any 
modification  of  the  TCB  code,  even  by  authorized  users  in  the  System  Programmer 
role,  may  invalidate  the  system's  rating.  The  above  measures  allow  the  design  of  a 
system  whose  mode  of  operation  does  not  include  an  all-powerful  role. 


The  Auditor  s  functions,  databases,  and  access  privileges  differ  significantly  from 
those  of  the  other  administrative  roles  (e  g.  Security  Administrator,  Account  Admin¬ 
istrator,  Operators).  The  separation  of  the  Auditor’s  functions,  databases,  and  access 
privileges  from  those  of  the  Security  Administrator,  Account  Administrator,  and  Op¬ 
erators  is  an  important  application  of  the  separation  of  privilege  and  least  privilege 
principles.  Should  such  separation  not  be  performed,  and  should  the  Security  Ad¬ 
ministrator  be  allowed  to  undertake  Auditor  functions  or  vice-versa,  the  entire 
security  function  would  become  the  responsibility  of  a  single,  unaccountable 
individual  or  role  in  normal  mode  of  system  operation.  For  example,  a  Security  Ad¬ 
ministrator  may  take  actions  that  represent  misuse  of  authority  and  then  use 
Auditor  functions  to  erase  any  evidence  of  his  actions.  Although  this  is  obviously 
undesirable,  the  TCSEC  does  not  require  the  separation  of  Security  Administrator 
and  Auditor  functions  (and  neither  does  it  require  the  separation  between  Secure 
Operator  and  Operator  functions). 

Figure  3  illustrates  both  the  fine-grained  separation  of  roles  and  of  databases/privi¬ 
leges.  The  relationships  between  the  different  roles  defined  here  are  explained  in 
Section  5.8. 

The  design  of  each  administrative  role  should  include  explicitly  the  set  of  commands, 
privileges,  and  databases  specific  to  that  role.  In  contrast,  the  assignment  of 
individuals  to  the  roles  is  best  left  to  the  management  of  the  installations  familiar 
with  the  skill,  interests,  and  trust  that  can  be  assigned  to  the  individuals. 
Furthermore,  this  guide  does  not  distinguish  between  the  role  of  the  System 
Programmer  of  a  specific  installation  and  that  assigned  to  a  manufacturer's  pro¬ 
grammer.  Such  distinctions  depend  on  the  operational  environment  and  adminis¬ 
trative  procedures  enforced  in  that  environment.  In  small  system  environments  the 
two  roles  become  indistinguishable,  whereas  in  large  system  environments  the  two 
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roles  are  different.  In  some  environments,  the  System  Programmer  has  the  right  to 
examine,  modify,  recompile,  and  rebuild  the  TCB,  whereas  in  others  the  System 
Programmer  can  only  install  a  given  object  code  version  of  it.  For  example,  it  is  not 
uncommon  that  System  Programmers  at  a  given  installation  site  add  device  drivers 
to  a  TCB  for  new  multilevel  devices  supported  in  the  systems,  and  then  rebuild  the 
TCB.  Whenever  the  System  Programmer  is  allowed  to  modify,  recompile,  and 
rebuild  the  TCB,  strict  configuration  management  procedures  should  be  followed  at 
the  installation  site  and  evidence  be  gathered  to  demonstrate  to  the  Accreditor  that 
the  system  rating  is  maintained  properly.  Again,  it  should  be  noted  that  any 
modification  to  the  evaluated  TCB  code  or  configuration  may  invalidate  the  system's 

rating. 

The  distinction  between  various  Operator's  ana  Administrators  functions  are 
established  by: 

(1)  who  performs  the  system  configuration,  distribution,  installation  and 
maintenance, 

(2)  who  defines  the  user  and  the  system  security  characteristics,  and 


(3)  who  performs  systems  operations  such  as  routine  maintenance  and 
response  to  user  requests.  This  section  recommends  a  more  structured 
separation  of  roles  that  provides  more  effective  management  of  the  com¬ 
puter  resources  and  accountability  for  those  personnel. 

5.1.  FUNCTIONS  OF  THE  SECURITY  ADMINISTRATOR 

The  security-relevant  functions  of  the  Security  Administrator  can  operate  at  more 
than  one  security  level  and  invoke  processes  or  programs  that  operate  with  some  sys¬ 
tem  privileges.  Thus,  these  functions  must  be  trusted  to  a  high  degree.  These  func¬ 
tions  include  identification  and  authentication  functions,  mandatory  access  control 
functions,  and  discretionary  access  control  functions. 

1.  The  identification  and  authentication  functions  of  the  Security  Admin¬ 

istrator  may  include: 

(a)  The  setting  of  the  parameters  of  the  log  in/out  mechanism,  such  as: 

•  timeout  period  (maximum  amount  of  time  the  system  waits 
for  the  next  command  or  for  the  completion  of  the  current 
command); 

•  maximum  login  time  (maximum  amount  of  time  the  user  may 
remain  logged  in  to  a  system); 

•  limit  of  successive  unsuccessful  tries  to  log  in  from  a  specific 
terminal  before  Administrators  are  notified; 

•  limit  of  successive  unsuccessful  tries  to  log  in  to  an  account, 
regardless  of  the  terminal  location,  before  Administrators  are 
notified; 

•  terminal  lockout  establishment  and  resetting; 

•  multiple  (simultaneous)  login  attributes; 


•  whether  a  specific  user's  login  needs  to  trigger  an  administra¬ 
tive  warning  (to  the  Administrator  or  to  the  Operator's 
console). 

(b) The  setting  of  the  authentication  parameters;  the  Security  Administra¬ 
tor  functions  may  include  those  that  carry  out  the  following  decisions: 

•  if  the  authentication  mechanism  is  password-based,  the  Secu¬ 
rity  Administrator  determines  the  password  characteristics 
(whether  the  user's  password  choice  is  user-generated  or  sys¬ 
tem-generated,  the  setting  of  the  minimum  and  maximum 
password  age,  the  password  complexity  parameters,  etc.); 

•  if  the  mechanism  is  dialogue-based,  the  Administrator  installs 
the  dialogue  programs  on  a  per-user  basis; 

•  the  Administrator  defines  and  manages  the  distribution  of 
special  passwords  for  the  trusted  processes  that  are  started  by 
passwords  (i.e.,  the  TCB  repair  and  maintenance  processes, 
such  as  security-label  repair,  etc.). 

[Note:  The  above  decisions  are  made  when  the  system  is  installed 
for  a  particular  organization,  and  the  system  Security  Adminis¬ 
trator  carries  out  the  installation  decisions  made  by  that 
organization.] 

(c)  The  definition  of  user  account  and  registration  profile;  this  definition 
may  include: 

•  user  identifier  (this  should  be  unique  for  the  lifetime  of  the 
system);  initial  user  password;  change  of  user  password; 

•  user's  full  name,  address,  and  affiliation; 

•  user's  group  identifiers  (these  should  also  be  unique  for  the 
lifetime  of  the  system); 
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user's  default  group 


(d)The  definition  of  group  accounts  and  registration  profile;  this  defini¬ 
tion  may  include: 

•  user  group  id  (this  should  be  unique  for  the  system's  lifetime); 

group  title,  group  administrator  identifier,  name  and  ad¬ 
dress; 

•  group  disk  quota; 

•  group  statistics. 

[Note:  In  some  environments,  the  user  and  the  group  identifiers 
of  registered  users  may  not  be  disclosed  to  other  users.  Note  also 
that,  whenever  the  TCB  does  not  automatically  create  unique 
identifiers  for  users  and  for  groups,  the  system  Security  Adminis¬ 
trator  does  not  reuse  user/group  names  until  he  is  certain  that 
name  conflicts  do  not  occur.] 


The  mandatory  access  control  functions  of  the  Security  Administrator  may 
include  the  following : 

(a)  Definition  and  maintenance  of  the  security  label  map;  this  includes 
functions  such  as  the  mapping  between  internal  representations  and 
human-readable  representations  of  security  lables. 


(b)  Setting  of  the  security-level  limits  and  the  default  security  levels  for: 

the  system,  the  users,  the  user  groups,  the  system  devices,  and  the  file 
systems. 


(c)  Labeling  of  imported  unlabeled  data,  and  unlabeled  media  such  as  disk 
packs. 


(d)  Reclassification  of  objects;  this  includes: 


•  object  upgrade  or  downgrade; 

•  label  overrides  on  user  output; 

•  restoration  of  damaged  labels  (whenever  this  function  is  not 
provided  by  the  System  Programmer  role). 

3.  The  discretionary  access  control  functions  of  the  Security  Administrator  may 
include  the  following : 

(a)  Initialization  of  the  discretionary  access  privileges  for  group  administra¬ 
tors  to  group  directories  and  group  devices;  also,  initialization  of 
storage  quotas  for  user  groups. 

(b)  Definition  and  maintenance  of  group  membership  (whenever  special 
group  administrators  are  not  supported). 

[Note:  Since  any  change  in  group  membership  affects  all  discretionary 
access  control  decisions  made  by  individual  users,  such  changes  should 
not  take  place  without  prior  consultation  with  the  users  who  may  be 
affected  by  this  decision.] 

(c)  Setting  of  discretionary  privileges  on  file  systems. 

(d)  Changes  of  object  ownership  in  systems  that  support  the  notion  of 
ownership;  also,  changes  of  discretionary  privileges  on  objects  whose 
privileges  are  accidentally  deleted  by  the  object's  creators  or  owners. 

(e)  Discretionary  distribution,  review,  and  revocation  of  privileges  on 
behalf  of  object  creators/owners  in  systems  that  do  not  allow  individual 
users  to  distribute,  review,  and  revoke  privileges  directly  (i.e.,  where 
the  control  of  object  sharing  is  centralized  [9]). 
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4.  Additional  functions  of  the  Security  Administrator  are  listed  below.  Specifically, 
the  Security  Administrator  may: 

(a)  Perform  consistency  checks  to  verify  that: 

•  the  database  of  user  and  system  security  profiles  satisfies  the 
system  security  requirements  and  is  in  a  consistent  state; 

•  the  TCB  is  installed  properly  (e.g.,  displays  and  checks  installa¬ 
tion  tables); 

•  the  TCB  does  not  contain  extraneous  programs  (e.g.,  pro¬ 
grams  that  are  privileged  but  are  not  part  of  the  TCB  con¬ 
figuration). 

(b)  Determine  that  the  current  system  configuration  is  within  the 
constraints  established  by  configuration  management  and  the  System 
Programmer.  This  includes  the  verification  of: 

•  device  and  terminal  registration; 

•  maximum  storage  size; 

•  file  (device)  system  name  table  and  file  (device)  mount  tables; 

•  device  and  terminal  connection  database. 

(c)  Terminate  user/group  accounts  (whenever  the  Account  Administrator  is 
not  defined  as  a  separate  role). 

(d)  Delete  user/group  accounts. 

(e)  Display  and  update  constants  of  various  system  tables. 

(f)  Initiate  and  analyze  the  system  integrity  tests. 
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(g)  Supervise  the  maintenance  procedures  (hardware,  etc  ). 


(h)  Respond  to  real-time  alarm  messages  (B3  and  higher). 

(i)  Destroy  errant  processes. 

(j)  Definition  of  the  site  identifier,  logo,  and  the  site  authentication  pro¬ 
tocols  within  a  network. 

(k)  Set  up  and  access  the  following  four  types  of  databases: 

•  The  database  of  the  user  and  system  security  profiles; 

•  The  security  label  map; 

•  The  file  system  hierarchy; 

•  The  system  configuration  database  (this  includes  the  current 
hardware  configuration  and  the  security-level  limits  of  the 
various  devices,  terminal  connections,  the  file-system  name 
and  mount  database,  etc.). 

All  the  modifications  to  these  databases  are  performed  by  the  Security  Administra¬ 
tor  using  the  commands  of  a  trusted  database  editor  and  the  system’s  trusted  path. 
Although  the  trusted  path  mechanism  is  not  required  for  these  modifications  in  class 
B2  systems,  the  trusted  editor  commands  are  part  of  the  administrative  interface 
commands  that  must  be  supported  by  all  trusted  systems.  All  actions  of  the  Security 
Administrators  are  audited. 

5.2.  FUNCTIONS  OF  THE  SECURE  OPERATOR 

The  security-relevant  functions  of  the  Operator  role  can  operate  across  more  than 
one  security  level  and  sometimes  invoke  processes  that  require  system  privileges. 
Thus,  these  functions  require  a  high  degree  of  trust.  An  Operator  who  executes 
security-relevant  operations  is  called  the  Secure  Operator.  These  functions  of  the 
Secure  Operator  may  include  the  following : 
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Booting  and  shutting  down  the  system;  setting  the  system's  clocks;  also,  set¬ 
ting  the  security  level  of  individual  system  devices  within  the  range  of  levels 
allowed  by  the  Security  Administrator's  database. 

[Note:  Shutting  down  the  system  requires  that  the  Operator  ensure  that 
appropriate  physical  and  administrative  security  features  be  in  place  to  pro¬ 
tect  the  information  while  the  system  is  not  running.  For  example,  shutting 
down  for  maintenance  might  require  that  the  date  be  removed  and  the  sys¬ 
tem  cleared.] 

Locating  damaged  user  files  and  volumes.  The  "salvager"  process  identifies 
damaged  labels  (e  g.,  labels  inconsistent  with  those  of  containing  directories 
and  files)  and  deletes  all  access  to  the  corresponding  objects  until  repair  is 
finished  by  the  System  Programmer  and  Security  Administrator. 

Performing  routine  maintenance  of  TCB  databases. 

The  Operator  performs  the  following  routine  maintenance  operations: 

•  audit  file  backup  (whenever  this  is  not  included  in  the  Auditor's 
role); 

•  security-level  changes  for  some  devices  (these  are  within  the  limits 
set  by  the  system  Security  Administrator); 

•  user  database  backup; 

•  security-map  backup; 

•  TCB  tables  backup. 

(It  must  be  noted  that  the  Operator  should  not  have  the  privilege  to  modify 
file  contents  for  file  backup.) 


Performing  on-line  terminal  and  device  tests  (including  authentication  tests). 


5.  Responding  to  user's  requests. 


The  Operator  should  be  able  to  respond  to  the  following  user  requests: 

•  mount/unmount  physically  (externally)  labeled  removable  media 
(e  g.,  tape  reels  and  disk  packs); 

•  import/export  other  physically  (externally)  labeled  data  into/from 
the  system. 

It  must  be  noted  that  all  Operator's  actions  must  be  auditable.  Mounting  unlabeled 
storage  devices  would  prevent  the  Operator's  actions  from  being  auditable  and  thus 
is  not  recommended.  The  TCB  needs  the  Label  information  in  order  to  make  correct 
access  control  decisions.  If  the  Operator  is  not  provided  the  label,  the  Operator 
through  the  system  will  not  be  able  to  enforce  the  policy  correctly. 


5.3.  FUNCTIONS  OF  THE  ACCOUNT  ADMINISTRATOR 

The  security-relevant  functions  of  the  Administrator  role  may  not  need  the  special 
privileges  to  operate  properly,  but  in  most  installations  they  will  be  trusted 
processes.  However,  all  output  generated  by  the  Account  Administrator  will  be 
marked  with  the  highest  security  level.  Otherwise,  leakage  of  classified  information 
may  take  place  (e  g.,  be  encoded  in  the  user  bills).  The  non-security-relevant  role  of 
the  Security  Administrator  is  called  the  Account  Administrator. 

The  (non-security-relevant)  functions  of  the  Account  Administrator  are  listed  below. 
Specifically,  the  Account  Administrator: 

1 .  Installs  and  maintains  accounting  files. 

2.  Turns  system  accounting  on  and  off. 


3.  Runs  accounting  tools  and  produces  accounting  reports/bills. 


4.  Enables  and  disables  accounts  at  users'  requests  (whenever  this  function  is 
not  provided  by  the  Security  Administrator);  however,  the  Account  Admin¬ 
istrator  does  not  have  the  privilege  to  define  or  change  the  users'  security 
profiles. 

5.  Establishes  the  billing  rates,  prices  and  policies. 

6.  On  a  regular  basis,  collects  system  statistics  such  as: 

•  system  availability; 

•  system  configuration; 

•  disk/CPU/memory  statistics. 

7.  Publishes  revenue/cost  reports. 

5.4.  FUNCTIONS  OF  THE  AUDITOR 

The  Auditor  role  invokes  processes  that  operate  with  system  privileges.  Thus,  all 
functions  of  the  Auditor  require  a  high  degree  of  trust.  These  functions  include 
those  that  enable  the  audit  selectivity  mechanism  (e.g.,  audit-event  setup  and 
change),  the  management  of  audit  trails,  the  setting  of  the  covert-channel  delays 
and  randomization  variables,  audit  data  compression  and  postprocessing  analysis 
[7],  Data  generated  by  the  Auditor  must  be  classified  at  the  System  High  level  since 
they  may  contain  information  generated  at  all  security  levels  defined  in  the  system. 
System  High  is  defined  as  the  security  label  that  dominates  all  other  security  labels  in 
the  system.  In  essence,  it  is  the  highest  possible  label.  It  would  be  beneficial,  and 
possibly  necessary,  to  create  the  System  High  level  such  that  it  is  hierarchically  higher 
than  all  the  data  levels  used  in  the  system.  This  approach  has  the  benefit  that  the 
mandatory  access  controls  provide  additional  protections  for  the  audit  data  if  the 
Auditor  is  the  only  one  authorized  forthis  level. 
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1.  The  Auditor  functions  that  define  the  events  recorded  in  the  audit  log  (or  trail) 
may  include: 

•  Functions  that  turn  on  and  off  events  that  should  be  recorded  in  the  au¬ 
dit  trail  to  ensure  the  consistency  of  subsequent  events  selected  by  the 
Auditor.  These  events  ensure  that  the  postprocessing  tools  function 
properly.  For  example,  in  systems  where  object-unique  names  are 
represented  by  file  system  pathnames,  any  change  to  the  working 
directory  relative  to  which  pathnames  are  interpreted,  should  be  au¬ 
dited.  (An  object-unique  name  is  the  unique  name  that  identifies  and 
distinguishes  a  particular  object  from  all  other  objects  in  a  system.  In  a 
hierarchical  file  system,  the  object-unique  name  includes  the  associated 
directory  names  so  users  can  use  the  same  name  for  objects  in  different 
directories).  Otherwise,  audit  analysis  tools  that  read  audit  events 
recorded  after  a  directory  change  cannot  identify  objects  unambigu¬ 
ously.  For  similar  reasons,  all  events  that  record  process  creation  or 
destruction  and  identification  or  authentication  actions  should  be 
selected  whenever  the  audit  is  on. 

•  Functions  that  display  all  security-relevant  events  which  can  be  audited. 
(The  determination  of  the  security-relevant  events  in  a  system  is  done 
at  design  time  and  is  based  on  the  interpretation  of  the  chosen  security 
policy  and  accountability  models  in  the  system.  Any  event,  such  as 
those  provided  by  a  user  invocation  of  a  TCB  or  trusted  process  call,  is 
security-relevant  if  it  causes  a  state  transition  or  if  it  denies  a  state 
transition  in  the  model's  interpretation.  For  example,  the  introduction 
of  an  object  in  an  address  space  of  a  process  is  security-relevant  in  a  sys¬ 
tem  designed  to  support  the  Bell-LaPadula  model  because  it  causes  a 
state  transition  in  the  interpretation  of  the  current-access-set  com¬ 
ponent  of  that  model's  interpretation  [2],  Similarly,  distribution  and 
revocation  of  access  privileges  cause  a  state  transition  because  they 
modify  the  access-matrix  component  of  the  model;  whereas  a  change 
in  security  level  of  an  object/subject  causes  a  state  transition  because  it 
modifies  the  security-function  component  of  the  model.  Other  state 
transitions,  which  should  also  be  audited,  may  modify  multiple  com¬ 
ponents  of  a  system  state;  e  g.,  the  creation/destruction  of  objects  that 
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modify  both  the  object  hierarchy  and  the  access  matrix.  Additional 
security-relevant  events  may  be  derived  from  the  interpretation  of  the 
trusted  facility  management  model  whenever  such  a  model  is  not 
included  in  the  security  policy  model.  Also,  additional  security-relevant 
events  may  be  derived  from  the  covert-channel  handling  requirements 
of  the  TCSEC). 


•  Functions  that  turn  on  or  off  audit  events  selectively  on  a  per-user,  per- 
process,  per-security-level  or  per-object  basis  are  also  included  here. 
These  events  may  be  signaled  by  the  processors,  TCB,  or  trusted  pro¬ 
cesses.  Selection  of  auditor-determined  subsets  of  these  events  should 
also  be  possible. 

•  Functions  that  turn  on  or  off  events  representing  accumulations  of 
other  auditable  events  (e.g.,  multiple  successive  unsuccessful  logins) 
and  alarms  are  also  included  here. 


2. 


Auditor  functions  that  help  manage  the  audit  files  may  include: 


•  Creation  and  destruction  of  audit  logs  and  postprocessing  audit  files. 

•  Change  of  audit-log  size  and  of  warning  points.  Warning  points  may 
be  expressed  as  a  specific  number,  or  percentage,  of  bytes  available  in 
the  audit  log.  When  these  warning  points  are  exceeded  by  the  event 
recording  mechanism,  an  auditor  warning  may  be  given  by  the  system. 
If  the  audit  log  becomes  full  and  the  audit  mechanism  is  on,  then  the 
system  may  stop  and  delay  further  activity  until  the  Auditor  takes 
corrective  action  [7], 


•  Functions  used  to  empty  full  audit  files. 

•  Functions  that  format  and  compress  events  in  the  audit  log  and 
postprocessing  audit  files.  The  formatting  functions  may  convert 
binary  audit  data  into  text  format  and  combine  partial  event  records 
into  the  required  record  format.  The  storing  of  formatted  postprocess- 
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ing  files  may  require  the  use  of  compression  techniques  to  improve 
storage  utilization. 

•  Functions  that  display  the  audit  log  and  postprocessing  audit  files  in 
various  formats. 

•  Consistency  checking  functions  which  operate  on  the  entire  auditor 
database  for  use  after  system  crashes. 

3.  Functions  that  set  the  delays  or  the  randomization  values  for  covert  channel 
handling  should  also  be  included  in  the  Auditor's  role.  The  reason  for  this  is  that 
the  covert  channel  handling  guideline  of  the  TCSEC  correlates  the  covert-channel 
audit  requirement  with  specific  covert-channel  bandwidth  values  and,  therefore, 
with  delay  values  and  randomization  ranges.  For  example,  depending  upon  the 
values  set  for  the  audit  delays,  specific  channels  may,  or  may  not,  need  to  be  au¬ 
dited.  Thus,  the  specification  of  the  delay  values  and  randomization  ranges 
becomes  the  duty  of  the  Auditor.  These  functions  may  include : 

•  The  setting  of  the  default  and  current  values  of  the  delays  for  single 
covert  channels  or  for  groups  of  covert  channels. 

•  The  setting  of  the  default  and  current  values  of  the  randomization 
ranges  for  covert  channels  arising  from  the  dynamic  allocation  or 
deallocation  of  indices  in  TCB  tables. 

4.  Functions  that  perform  the  postprocessing  of  the  audit  data  are  necessary  for  any 
audit  log  analysis  and,  therefore,  should  be  included  in  any  trusted  system. 
Although  some  of  these  functions  are  independent  of  the  required  audit  analysis, 
such  as  the  functions  that  retrieve  various  fields  of  the  audit  logs,  most  of  these 
functions  are  specific  to  the  postprocessing  analysis  required  by  specific  applica¬ 
tions. 

In  summary,  the  functions  of  the  Auditor  role  may  set  up,  access  and  modify  the 

following  types  of  databases: 
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•  audit  log  files  containing  full  or  partial  records  of  audit  events  in  binary 
or  text  formats; 

•  audit  event  file  containing  the  definition  of  all  auditable  events  in  the 
system; 

•  selected-event  file  containing  the  definitions  of  all  events  selected  on  a 
per-user,  per-process,  per-security-level,  per-object  basis; 

•  formatted  or  compressed  audit  files  containing  the  input  to  the 
postprocessing  phase; 

•  audit  report  files. 

Access  to  the  audit  databases  may  be  performed  only  by  individuals  who  can  assume 
the  Auditor  role,  using  the  commands  defined  for  that  role.  Use  of  Auditor 
commands  must  be  audited.  For  class  B3  and  above  systems,  the  use  of  Auditor 
commands  must  be  through  the  trusted  path  mechanism. 


5.5.  FUNCTIONS  OF  THE  OPERATOR 


The  security-relevant  functions  of  the  Operator  role  do  not  need  all  the  system  privi¬ 
leges  to  operate  properly.  However,  the  Operator  should  be  able  to  change  the 
authorization  of  his  processes  between  System  Low  and  System  High  because  he  may 
need  to  operate  at  different  security  levels.  System  Low  is  the  security  label  that  is 
dominated  by  all  other  security  labels  in  the  system.  In  essence,  it  is  the  lowest 
possible  label. 

The  security-relevant  functions  of  the  Operator  are  defined  below.  Specifically,  the 
Operator: 

1.  Performs  user  volume  backup.  This  includes: 

•  complete  volume  dumps; 

•  complete  volume  retrievals. 

2.  Performs  system  performance  metering. 

3.  Responds  to  various  other  user  requests  (request  for  the  installation  of 
user-level  software  packages,  etc.). 

4.  Adjusts  resource  quotas  for  user-visible  resources. 

5.6.  FUNCTIONS  OF  THE  SYSTEM  PROGRAMMER 

The  functions  of  the  System  Programmer  role  are  the  most  security-sensitive  func¬ 
tions  of  the  system.  They  may  affect  the  TCB  configuration,  distribution  and  mainte¬ 
nance.  These  functions  are  not  necessarily  audited  and,  thus,  any  error,  omission,  or 
malicious  act,  may  affect  the  security  of  the  entire  system  and  may  remain 
undetected.  (However,  some  form  of  auditing,  possibly  off-line,  is  still  necessary  in 
some  environments.  Multiple  System  Programmers  checking  each  others'  actions 
may  also  be  required  in  some  environments  for  the  execution  of  the  System 
Programmer  functions.  Furthermore,  a  two-person  rule  may  be  instituted  or  built 
into  the  login  procedure  requiring  that  a  System  Programmer  may  not  log  in 


successfully  unless  another  System  Programmer  is  also  logging  in).  Thus,  the  System 
Programmer  functions  should  have  the  highest  degree  of  trust  in  the  system.  The 
System  Programmer  functions  may  include  the  following: 

1.  Trusted  system  distribution;  for  example,  this  includes  the  generation  and 
handling  of  the  site's  system  master  copy. 

2.  Setting  of  system  configuration  parameters  (as  specified  by  the  site's  con¬ 
figuration  management  policy);  for  example,  this  includes: 


•  generic  system  configuration; 

•  initialization  of  the  TCB  data  structures  (before  any  security  profiles 
or  audit  characteristics  are  defined); 


•  loading  of  the  TCB. 

3.  Nonroutine  TCB  maintenance;  for  example,  this  includes: 


•  analysis  of  dumps; 

•  installation  of  "patches"  to  the  TCB  code  and  data  (for  this  the  Op¬ 
erator  should  be  able  to  recompile  TCB  code  from  modified  source 
code  and  should  use  a  trusted  loader  to  reload  the  system); 

•  trusted  recovery  actions  after  system  crashes;  for  example,  the  Oper¬ 
ator  performs  consistency  checks  on  the  file  system  structure,  on 
individual  TCB  files,  directories  and  tables,  and  repairs  damaged 
labels; 

•  repairs  damaged  security  labels  whenever  this  function  is  not  pro¬ 
vided  by  the  Security  Administrator  role  (damaged  labels  identified 
by  Secure  Operators  or  Users). 
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The  databases  of  the  System  Programmer  include: 


•  all  TCB  files  (e  g.,  TCB  code,  security-map,  auditor  files); 

•  all  TCB  tables  (e.g.,  interrupt  vectors,  trap  tables,  gates). 

5.7.  OTHER  ROLES 

Other  administrative  roles  can  be  defined  in  a  secure  system.  For  example,  in  certain 
environments  the  role  of  the  Analyst  can  be  defined.  An  Analyst  may  be  an 
otherwise  unprivileged  user  who  is  trusted  to  label  imported  data  from  various  sys¬ 
tem  inputs,  to  create  new  files  and  label  them  as  he  sees  fit.  The  Analyst  cannot 
label  any  data  file  with  a  security  level  higher  than  his  or  her  maximum  clearance. 
All  the  Analyst  s  actions  are  audited,  as  are  those  of  a  normal  user. 

When  a  system  is  tied  into  a  network,  additional  roles  may  be  necessary  to  ensure 
consistency  and  accuracy  of  the  network  policy  enforcement.  Such  roles  could 
involve  additional  security-relevant  databases. 

5.8.  RELATIONSHIP  AMONG  ADMINISTRATIVE  ROLES 

The  fine-grained  separation  of  administrative  roles  defined  above  permits  the 
establishment  of  a  hierarchical  relationship  among  administrative  roles  based  on  a 
notion  of  role  dominance  (not  to  be  confused  with  the  notion  of  dominance 
among  security  or  integrity  levels).  This  notion  signifies  the  ability  of  an  administra¬ 
tive  user  in  a  certain  role  to  change  the  attributes  of  objects  and  security  profiles  of 
users  in  other  roles  and,  if  necessary,  to  log  in  and  take  actions  in  that  role. 

Object  attributes  include: 

•  access  privileges; 

•  size; 


security  and  integrity  levels;  and 


•  ownership. 


Profile  attributes  include: 

•  user  and  group  identifiers; 

•  passwords; 

•  group  membership;  and 

•  time  restrictions  on  user  activity. 

The  above  notion  of  role  dominance  can  be  useful  because  it  provides  both  a 
measure  of  necessary  trust  (based  on  skills,  on  checking  administrative  users' 
background  and  interests,  etc.)  that  should  be  invested  in  a  role  and  a  measure  of 
vulnerability  associated  with  that  role.  The  most  privileged  role  is  that  of  the  System 
Programmer.  It  dominates  all  other  roles  in  the  system  and,  consequently,  it  exhibits 
the  highest  degree  of  vulnerability.  The  Auditor  role  should  be  strictly  separated 
from  all  other  remaining  roles  defined  in  the  system  because  it  maintains  sensitive 
information  describing  the  behavior  of  all  users,  including  the  administrative  ones. 
The  Security  Administrator  dominates  the  Secure  Operator,  Account  Administrator, 
Analyst,  and  user  roles;  however,  the  dominated  roles  are  separated  from  each 
other.  It  must  be  noted  that  users  in  the  same  role  do  not  dominate  each  other. 
Although  they  share  most  functions,  privileges,  and  databases  of  the  common  role, 
their  security  profiles  are  disjoint  to  allow  individual  accountability.  This  helps  dist¬ 
inguish  the  activities  of  individual  users  in  the  same  role.  Figure  4  illustrates  the  rela¬ 
tionship  among  the  administrative  roles  defined  above.  The  system  could  provide  a 
"flat"  set  of  roles,  functions  and  privileges,  and  the  role  relationships  that  could  be 
managed  administratively.  Implementations  of  hierarchical  relationships  among 
administrative  roles  can  benefit  from  the  use  of  mandatory  security  and,  especially, 
integrity  models.  Mandatory  integrity  models,  such  as  the  Biba  model  [4]  and  the 
Clark-Wilson  model  [8],  could  be  used  to  guide  the  design  of  the  above-mentioned 
roles  and  hierarchical  relationships,  as  discussed  below. 


System 


\ 


A  may  log  in  as  B 


Relationships  Among  Administrative  Roles  [  See  also  Figure  3] 

Figure  4 
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6.  IMPACT  OF  OTHER  TCSEC  REQUIREMENTS  ON  TRUSTED  FACILITY 
MANAGEMENT 


The  major  areas  of  the  TCSEC  requirements  (security  policy,  accountability,  assurance 
and  documentation)  impact  on  trusted  facility  management.  The  design  and  imple¬ 
mentation  of  the  functions  of  various  administrative  roles  may  use  some  of  the  secu¬ 
rity  mechanisms  and  policies  of  the  underlying  system  to  implement  some  of  their 
special  protection  requirements  or  may  choose  to  implement  new  protection 
mechanisms  and  policies.  For  example,  the  implementors  of  Security  Administrator 
functions  may  use  the  discretionary  access  control  mechanisms  or  may  choose  to 
implement  to  protect  the  Security  Administrator  databases  from  other  administra¬ 
tive  users  and  from  normal  users.  This  section  examines  the  relationship  of  other 
TCSEC  requirements  to  trusted  facility  management. 

6.1.  SECURITY  POLICY 


To  support  the  system's  security  policies,  the  functions  of  trusted  facility  manage¬ 
ment  must  control  access  to  and  sharing  of,  administrative  data.  Trusted  processes 
implementing  the  security  functions  of  the  Administrator's  and  Operator’s  role  share 
files  of  the  administrative  database  in  a  variety  of  ways.  Some  files  are  private  to 
each  role  and  are  never  shared  with  other  roles,  with  other  users  of  the  same  role,  or 
with  nonadministrative  trusted  processes.  For  example,  the  security  label  map  file  is 
private  to  the  Security  Administrator  role,  the  audit  log  and  the  postprocessing  audit 
files  are  private  to  the  Auditor  role,  and  the  accounting  files  are  private  to  the 
Account  Administrator  role.  All  such  files  are  shared  among  all  users  of  the  same 
role.  Other  files,  such  as  those  containing  the  user  and  group  registration,  may  be 
shared  between  processes  of  different  roles.  These  files  may  be  read  and  written  by 
Security  Administrator  processes,  and  are  read  by  Auditor,  Secure  Operator  and 
Account  Administrator  processes.  Account  Administrators  and  Operators  may 
perform  special  tasks,  such  as  the  collection  of  user  and  system  statistics  and 
performance  metering,  for  which  they  would  create  and  maintain  private  files 
(those  not  shared  with  others  in  the  same  role).  Furthermore,  other  files  are  shared 
between  processes  of  an  administrative  role  and  nonadministrative  trusted  pro¬ 
cesses.  For  example,  the  user  password  file  is  read  and  written  by  the  Security  Ad¬ 
ministrator  role,  read  by  the  "login"  trusted  process,  and  read  and  written  by  the 
"change-password"  trusted  process,  which  can  be  invoked  by  any  user. 
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To  control  access  to  administrative  data  and  to  implement  the  above-mentioned 
sharing  relationships  among  processes  of  the  administrative  roles,  the  design  and 
implementation  of  trusted  facility  management  may,  or  may  not,  rely  on  discre¬ 
tionary  and  mandatory  access  controls  of  the  underlying  system.  If  they  do,  some 
processes  implementing  role  functions,  which  need  to  read  and  write  files  at  all  secu¬ 
rity  levels  (e  g.,  Accounting,  Auditor,  and  Secure  Operator  processes),  would  need  to 
bypass  the  mandatory  access  controls  at  least  occasionally.  Some  other  processes  will 
operate  at  the  highest  level  in  the  system  (e.g.,  accounting  and  audit  processes)  and 
maintain  data  files  at  this  level  (e.g.,  audit  log  and  postprocessing  files,  accounting 
files). 

Whenever  the  sharing  relationships  among  programs  and  processes  of  the  adminis¬ 
trative  roles  cannot  be  supported  by  existing  mechanisms,  new  mechanisms  have  to 
be  introduced.  For  example,  the  association  of  specific  programs  implementing 
administrative  functions  with  roles  may  require  the  implementation  of  restricted 
command  processors,  of  restricted  groups  that  cannot  be  modified  by  the  Security 
Administrator,  or  of  other  more  complex  integrity  mechanisms  (discussed  below).  In 
all  such  cases,  the  design  and  implementation  of  trusted  facility  management  func¬ 
tions  should  follow  existing  guidelines. 


6.2.  ACCOUNTABILITY 


The  accountability  requirements  of  the  TCSEC  impose  several  constraints  on  the 
implementation  of  trusted  facility  management,  in  addition  to  the  separation  of 
roles.  First,  the  identification  and  authentication  of  all  administrative  users  must  be 
unambiguous  and  must  be  done  on  an  individual  basis,  not  on  a  per-role  basis.  For 
example,  if  all  users  of  a  role  share  the  same  password,  accountability  will  be  lost 
since  any  user  can  take  the  identity  of  other  users  of  the  same  role  and  commit  acts 
of  intrusion  attributable  to  those  users. 


Second,  the  trusted-path  mechanism  for  classes  B3  and  above  must  ensure  that  the 
administrative  users  are  connected  to  the  commands  or  processes  that  belong  to 
their  role,  and  that  no  other  users  or  processes  can  interpose  themselves  into  the 
path  connecting  any  combination  of  the  administrative  users,  their  commands,  and 
their  processes.  This  can  be  accomplished  by  providing  administrative  consoles 
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recognized  and  separated  by  the  TCB  hardware  or  software  from  the  rest  of  the 
terminals,  or  by  the  design  of  a  full  (i.e.,  B3-A1)  trusted-path  mechanism. 


Third,  use  of  all  administrative  functions,  other  than  those  used  by  System  Pro¬ 
grammers  in  maintenance  mode,  must  be  audited.  This  implies  that  trusted  pro¬ 
grams  and  processes  implementing  these  commands  should  be  able  to  request  the 
writing  of  audit  records  during  the  execution  of  those  commands.  In  all  areas  of 
accountability,  the  design  and  implementation  of  trusted  facility  management  func¬ 
tions  should  follow  existing  guidelines. 

6.3.  ASSURANCE 

The  assurance  requirements  of  the  TCSEC  have  a  significant  impact  on  trusted  facility 
management  both  in  the  operational  and  in  the  life-cycle  areas.  These  requirements 
affect  both  the  design  and  the  implementation  of  the  trusted  facility  management 
functions. 


6.3.1.  Operational  Assurance 

The  only  relevant  areas  of  operational  assurance  are  the  system  architecture  and  the 
trusted  recovery  areas.  The  covert  channel  analysis  area  is  not  relevant  here  because 
(1)  all  users  in  security-relevant  administrative  roles  have  been  screened  for  this  posi¬ 
tion  of  trust  and  are  therefore  expected  not  to  disclose  information  in  an  unautho¬ 
rized  way,  and  (2)  all  code  implementing  administrative  functions  is  reviewed  to 
ensure,  to  the  largest  possible  extent,  that  no  Trojan  horses  are  present.  The  system 
integrity  requirements  of  the  TCSEC  are  also  irrelevant  here  as  they  deal  only  with 
the  test  of  proper  hardware  and  firmware  operation. 


The  system  architecture  requirements  impose  major  constraints  on  the  design  of 
trusted  facility  management.  Because  all  the  security-relevant  and  accountability 
functions  of  the  administrative  roles  are  part  of  a  system's  TCB,  all  requirements  of 
TCB  interface  definition  apply  to  the  administrative  interfaces.  Similarly,  all  require¬ 
ments  of  internal  TCB  structuring,  such  as  those  of  modularity,  abstraction,  informa¬ 
tion  hiding,  and  layering  apply  to  the  design  and  implementation  code  of  the  pro¬ 
grams  and  processes  of  trusted  facility  management.  Careful  analysis  and 
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documentation  of  this  design  and  implementation  area,  as  well  as  careful  scrutiny 
by  evaluators,  is  expected  in  this  area. 

The  application  of  the  least  privilege  principle  to  the  design  of  trusted  processes  is 
also  required  of  the  administrative  processes  of  the  TCB.  Several  specific  design 
requirements  should  be  observed  here.  First,  the  protection  of  the  administrative 
databases  should  be  performed  at  the  granularity  of  individual  files  (or  segments) 
and  individual  privileges.  (The  term  file  is  used  here  in  a  generic  sense  to  represent  a 
logically  small  structure  such  that  the  structure  does  not  include  information 
unrelated  to  the  specific  function).  Second,  programs  and  processes  of  the  adminis¬ 
trative  roles  should  have  access  only  to  the  TCB  and  user  files,  and  to  the  privileged 
TCB  calls,  that  are  necessary  for  implementing  those  roles,  but  to  no  other  files  or 
calls.  Several  design  alternatives  are  available  in  this  area.  For  example,  certain  files 
should  be  associated  only  with  certain  processes.  Privileged  TCB  calls,  which  can  be 
represented  by  ring-gate  descriptors  [15,19],  domain-entry  capabilities  [13],  or  per- 
process  privilege  vectors  corresponding  to  specific  calls  [16,14],  should  be  associated 
with  processes  only  on  an  "as  needed"  basis.  These  associations  can  be  controlled  by 
careful  application  of  nondiscretionary  labels  and  authorizations  at  system 
configuration  or  installation  time. 

The  only  specific  requirement  of  trusted  recovery  imposed  on  the  design  and  imple¬ 
mentation  of  trusted  facility  management  is  that  the  consistency  of  the  administra¬ 
tive  databases  be  maintained  after  system  crashes.  This  requirement  can  be  satisfied 
by  ensuring  that  : 

•  these  databases  are  stored  on  nonvolatile  storage  that  survives  sys¬ 
tem  crashes; 

•  that  updates  to  such  storage  are  atomic; 

•  that  at  least  one  of  the  administrative  roles  is  equipped  with 
commands  for  checking  the  consistency  of  the  administrative  file 
contents.  Note  that  this  could  be  a  fully  automated  mechanism  not 
requiring  administrator  interaction. 


6.3.2.  Life-Cycle  Assurance 


Most  life-cycle  assurance  requirements  apply  to  the  processes  and  interfaces  of 
trusted  facility  management  as  stated.  For  example,  security  testing,  configuration 
management,  and  trusted  distribution  requirements  of  the  TCB  apply  to  trusted 
facility  management  to  the  degree  of  rigor  commensurate  with  the  chosen  evalua¬ 
tion  class.  This  is  the  case  because  the  TCB  code  and  interfaces  include  the  security¬ 
relevant  code  and  interfaces  of  trusted  facility  management. 

In  contrast,  only  some  of  the  requirements  of  the  design  specification  and  verifica¬ 
tion  area  apply  to  the  trusted  facility  management  directly.  For  example,  the  need 
for  accurate  DTLSs  for  the  TCB  interfaces  applies  as  stated.  However,  the  require¬ 
ments  for  a  formal  model,  for  an  interpretation  of  this  model  in  the  DTLSs  of  the 
trusted  facility  management  part  of  the  TCB,  and  for  a  convincing  argument  that  the 
DTLSs  are  consistent  with  the  model  are  not  directly  applicable  here.  The  reason  for 
this  is  that  no  generally  acceptable  formal  model  of  the  trusted  facility  management 
area  exists  to  date.  Should  a  generally  acceptable  formal  model  become  available, 
then  all  requirements  of  the  design  specification  and  verification  area  would  apply 
to  trusted  facility  management  directly. 

6.4.  DOCUMENTATION 

The  documentation  requirements  of  the  TCSEC  relevant  to  the  trusted  facility  man¬ 
agement  area  are  the  trusted  facility  manual  requirements  in  Section  3,  the  test 
documentation  requirements,  and  some  of  the  design  documentation  [8],  In  the 
design  documentation  area,  only  the  requirements  referring  to  the  DTLSs,  TCB 
internal  structuring,  and  enforcement  of  the  least  privilege  principle  are  relevant. 
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Access 

A  specific  type  of  interaction  between  a  subject  and  an  object  that  results  in 
the  flow  of  information  from  one  to  the  other. 

Account  Administrator 

An  administrative  role  or  user  assigned  to  maintain  accounting  files,  tools, 
user  accounts,  and  system  statistics. 

Accreditation 

A  formal  declaration  by  the  DAA  that  the  AIS  is  approved  to  operate  in  a 
particular  security  mode  using  a  prescribed  set  of  safeguards.  Accreditation  is 
the  official  management  authorization  for  operation  of  an  AIS  and  is  based 
on  the  certification  process  as  well  as  other  management  considerations.  The 
accreditation  statement  affixes  security  responsibility  with  the  DAA  and 
shows  that  due  care  has  been  taken  for  security. 

Administrative  User 

A  user  assigned  to  supervise  all  or  a  portion  of  an  AIS. 

Administrator 

See  Administrative  User. 


Audit 

To  conduct  the  independent  review  and  examination  of  system  records  and 
activities. 

Audit  Event  Selection 

Selection,  by  authorized  personnel,  of  the  auditable  events  that  are  to  be 
recorded  on  the  audit  trail. 


Audit  Mechanism 

The  processes  used  to  collect,  review,  and/or  examine  system  activities. 


Audit  Postprocessing 

Processing,  under  the  control  of  authorized  personnel,  of  specified  events 
that  had  been  recorded  on  the  audit  trail. 

Audit  Trail 

A  chronological  record  of  system  activities  that  is  sufficient  to  enable  the  re¬ 
construction,  reviewing,  and  examination  of  the  sequence  of  environments 
and  activities  surrounding  or  leading  to  an  operation,  a  procedure,  or  an 
event  in  a  transaction  from  its  inception  to  final  results. 

Auditable  Event 

Any  event  that  can  be  selected  for  inclusion  in  the  audit  trail.  These  events 
should  include,  in  addition  to  security-relevant  events,  actions  taken  to  re¬ 
cover  the  system  after  failure  and  any  events  that  might  prove  to  be  security¬ 
relevant  at  a  later  time. 

Auditor 

An  authorized  individual,  or  role,  with  administrative  duties,  which  include 
selecting  the  events  to  be  audited  on  the  system,  setting  up  the  audit  pa¬ 
rameters  which  enable  the  recording  of  those  events,  and  analyzing  the  trail 
of  audit  events. 

Authenticate 

(1)  To  verify  the  identity  of  a  user,  device,  or  other  entity  in  a  computer  sys¬ 
tem,  often  as  a  prerequisite  to  allowing  access  to  resources  in  a  system. 

(2)  To  verify  the  integrity  of  data  that  have  been  stored,  transmitted,  or 
otherwise  exposed  to  possible  unauthorized  modification. 

Authenticated  User 

A  user  who  has  accessed  an  AIS  with  a  valid  identifier  and  authentication 
combination. 


Automated  Information  System  (AIS) 

An  assembly  of  computer  hardware,  software  and/or  firmware  configured  to 
collect,  create,  communicate,  compute,  disseminate,  process,  store,  and/or 
control  data  or  information. 

Bandwidth 

A  characteristic  of  a  communication  channel  that  is  the  amount  of  informa¬ 
tion  that  can  be  passed  through  it  in  a  given  amount  of  time,  usually  ex¬ 
pressed  in  bits  per  second. 

Category 

A  restrictive  label  that  has  been  applied  to  classified  or  unclassified  data  as  a 
means  of  increasing  the  protection  of  the  data  and  further  restricting  access 
to  the  data. 

Channel 

An  information  transfer  path  within  a  system.  May  also  refer  to  the  mech¬ 
anism  by  which  the  path  is  effected. 

Covert  Channel 

A  communication  channel  that  allows  two  cooperating  processes  to  transfer 
information  in  a  manner  that  violates  the  system's  security  policy. 

Covert  Storage  Channel 

A  covert  channel  that  involves  the  direct  or  indirect  writing  of  a  storage  loca¬ 
tion  by  one  process  and  the  direct  or  indirect  reading  of  the  storage  location 
by  another  process.  Covert  storage  channels  typically  involve  a  finite  resource 
(e  g.,  sectors  on  a  disk)  that  is  shared  by  two  subjects  at  different  security  lev¬ 
els. 

Covert  Timing  Channel 

A  covert  channel  in  which  one  process  signals  information  to  another  by  mod¬ 
ulating  its  own  use  of  system  resources  (e.g.,  CPU  time)  in  such  a  way  that  this 
manipulation  affects  the  real  response  time  observed  by  the  second  process. 


Data 


Information  with  a  specific  physical  representation. 

Data  Integrity 

The  property  that  data  meet  an  a  priori  expectation  of  quality. 

Descriptive  Top-Level  Specification  (DTLS) 

A  top-level  specification  that  is  written  in  a  natural  language  (e.g.,  English), 
an  informal  program  design  notation,  or  a  combination  of  the  two. 

Discretionary  Access  Control 

A  means  of  restricting  access  to  objects  based  on  the  identity  and  need-to- 
know  of  the  user,  process  and/or  groups  to  which  they  belong.  The  controls 
are  discretionary  in  the  sense  that  a  subject  with  a  certain  access  permission  is 
capable  of  passing  that  permission  (perhaps  indirectly)  on  to  any  other 
subject. 

Formal  Security  Policy  Model 

A  mathematically  precise  statement  of  a  security  policy.  To  be  adequately 
precise,  such  a  model  must  represent  the  initial  state  of  a  system,  the  way  in 
which  the  system  progresses  from  one  state  to  another,  and  a  definition  of  a 
"secure"  state  of  the  system.  To  be  acceptable  as  a  basis  for  a  TCB,  the  model 
must  be  supported  by  a  formal  proof  that  if  the  initial  state  of  the  system 
satisfies  the  definition  of  a  "secure"  state  and  if  all  assumptions  required  by 
the  model  hold,  then  all  future  states  of  the  system  will  be  secure.  Some  for¬ 
mal  modeling  techniques  include:  state  transition  models,  temporal  logic 
models,  denotational  semantics  models,  and  algebraic  specification  models. 

Formal  Top-Level  Specification  (FTLS) 

A  Top-Level  Specification  that  is  written  in  a  formal  mathematical  language  to 
allow  theorems  showing  the  correspondence  of  the  system  specification  to  its 
formal  requirements  to  be  hypothesized  and  formally  proven. 

Functional  Testing 

The  segment  of  security  testing  in  which  the  advertised  features  of  a  system 
are  tested,  under  operational  conditions,  for  correct  operation. 


Least  Privilege 

The  principle  that  requires  that  each  subject  be  granted  the  most  restrictive 
set  of  privileges  needed  for  the  performance  of  authorized  tasks.  The  applica¬ 
tion  of  this  principle  limits  the  damage  that  can  result  from  accident,  error,  or 
unauthorized  use. 

Mandatory  Access  Control 

A  means  of  restricting  access  to  objects  based  on  the  sensitivity  (as 
represented  by  a  label)  of  the  information  contained  in  the  objects  and  the 
formal  authorization  (i.e.,  clearance)  of  subjects  to  access  information  of  such 
sensitivity. 

Multilevel  Device 

A  device  that  is  used  in  a  manner  that  permits  it  to  process  data  simultane¬ 
ously  of  two  or  more  security  levels  without  risk  of  compromise.  To  accom¬ 
plish  this,  sensitivity  labels  are  normally  stored  on  the  same  physical  medium 
and  in  the  same  form  (i.e.,  machine-readable  or  human-readable)  as  the  data 
being  processed. 

Multilevel  Secure 

A  class  of  system  containing  information  with  different  sensitivities  that 
simultaneously  permits  access  by  users  with  different  security  clearances  and 
needs-to-know,  but  prevents  users  from  obtaining  access  to  information  for 
which  they  lack  authorization. 

Object 

A  passive  entity  that  contains  or  receives  information.  Access  to  an  object 
potentially  implies  access  to  the  information  it  contains.  Examples  of  objects 
are:  records,  blocks,  pages,  segments,  files,  directories,  directory  trees,  and 
programs,  as  well  as  bits,  bytes,  words,  fields,  processors,  video  displays,  key¬ 
boards,  clocks,  printers,  network  nodes. 
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Object-Unique  Names 

The  unique  name  that  identifies  and  distinguishes  a  particular  object  from  all 
other  objects  in  a  system.  In  a  hierarchical  file  system,  the  object-unique  name 
includes  the  associated  directory  names  so  users  can  use  the  same  name  for 
objects  in  different  directories. 

Operator 

An  administrative  role  or  user  assigned  to  perform  routine  maintenance 
operations  of  the  AIS  and  to  respond  to  routine  user  requests. 

Output 

Information  that  has  been  exported  by  a  TCB. 

Password 

A  protected/private  character  string  that  is  used  to  authenticate  an  identity. 

Process 

A  program  in  execution. 


Read 

A  fundamental  operation  that  results  only  in  the  flow  of  information  from  an 
object  to  a  subject. 

Read  Access  (Read  Privilege) 

Permission  to  read  information. 

Secure  Operator 

An  administrative  role  (or  user)  assigned  to  perform  those  aspects  of  the  Op¬ 
erator  role  that  can  affect  the  security  relevant  data  used  by  the  TCB  to  en¬ 
force  its  policy  (e.g.,  notifying  the  TCB  of  the  security  label  of  a  newly 
mounted  tape). 


Security  Administrator 

An  administrative  role  (or  user)  responsible  for  the  security  of  an  Automated 
Information  System  and  having  the  authority  to  enforce  the  security  safe¬ 
guards  on  all  others  who  have  access  to  the  Automated  Information  System 
(with  the  possible  exception  of  the  Auditor).  Also  called  System  Administra¬ 
tor. 

Security  Label  Map 

A  map  defining  the  correspondence  between  the  binary  and  ASCII  formats  of 
security  levels  (e  g.,  between  binary  format  of  security  levels  and  sensitivity 
labels). 

Security  Level 

The  combination  of  a  hierarchical  classification  and  a  set  of  nonhierarchical 
categories  that  represents  the  sensitivity  of  information. 

Security  Policy 

The  set  of  laws,  rules,  and  practices  that  regulate  how  an  organization  man¬ 
ages,  protects,  and  distributes  sensitive  information. 

Security  Policy  Model 

A  formal  presentation  of  the  security  policy  enforced  by  the  system.  It  must 
identify  the  set  of  rules  and  practices  that  regulate  how  a  system  manages, 
protects,  and  distributes  sensitive  information. 

Security-Relevant  Event 

Any  event  that  attempts  to  change  the  security  state  of  the  system,  (e  g., 
change  discretionary  access  controls,  change  the  security  level  of  the  subject, 
change  user  passwora,  etc.).  Also,  any  event  that  attempts  to  violate  the  secu¬ 
rity  policy  of  the  system  (e  g.,  too  many  attempts  to  login,  attempts  to  violate 
the  mandatory  access  control  limits  of  a  device,  attempts  to  downgrade  a  file, 
etc.). 


Security  Testing 

A  process  used  to  determine  that  the  security  features  of  a  system  are  imple¬ 
mented  as  designed.  This  includes  hands-on  functional  testing,  penetration 
testing,  and  verification. 

Sensitive  Information 

Any  information,  the  loss,  misuse,  modification  of,  or  unauthorized  access  to, 
could  affect  the  national  interest  or  the  conduct  of  Federal  programs,  or  the 
privacy  to  which  individuals  are  entitled  under  Section  552a  of  Title  5,  U.S. 
Code,  but  that  has  not  been  specifically  authorized  under  criteria  established 
by  an  Executive  order  or  an  act  of  Congress  to  be  kept  classified  in  the  interest 
of  national  defense  or  foreign  policy. 

Sensitivity  Label 

A  piece  of  information  that  represents  the  security  level  of  an  object.  Sensitiv¬ 
ity  labels  are  used  by  the  TCB  as  the  basis  for  mandatory  access  control  deci¬ 
sions. 

Separation  of  Privilege 

The  separation  of  functions,  namely  between  the  commands,  programs,  and 
interfaces  implementing  those  functions,  such  that  malicious  or  erroneous 
code  in  one  function  is  prevented  from  affecting  the  code  or  data  of  another 
function. 

Spoofing 

An  attempt  to  gain  access  to  a  system  by  posing  as  an  authorized  user.  Also 
called  masquerading  or  mimicking. 

Subject 

An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device  that 
causes  information  to  flow  among  objects  or  changes  the  system  state. 
Technically,  a  process/domain  pair. 


Subject  Security  Level 

A  subject’s  security  level  is  equal  to  the  security  level  of  the  objects  to  which  it 
has  both  read  and  write  access.  A  subject's  security  level  must  always  be 
dominated  by  the  clearance  of  the  user  with  the  subject  is  associated. 

System  Administrator 

See  Security  Administrator. 

System  High 

An  AIS  is  operating  in  the  system-high  mode  when  each  user  with  direct  or 
indirect  access  to  the  AIS,  its  peripherals,  remote  terminals,  or  remote  hosts 
has  all  of  the  following : 

a.  A  valid  personnel  clearance  for  all  information  on  the  AIS. 

b.  Formal  access  approval  for,  and  has  signed  nondisclosure 
agreements  for,  all  the  information  stored  and/or  processed 
(including  all  compartments,  subcompartments,  and/or  special 
access  programs). 

c.  A  valid  need-to-know  for  some  of  the  information  contained  within 
the  AIS. 


System  Low 

The  lowest  security  level  supported  by  a  system  at  a  particular  time  or  in  a  par¬ 
ticular  environment. 

System  Programmer 

An  administrative  role  (or  user)  responsible  for  trusted  system  distribution, 
configuration,  installation,  and  nonroutine  maintenance. 

Top-Level  Specification  (TLS) 

A  nonprocedural  description  of  system  behavior  at  the  most  abstract  level; 
typically,  a  functional  specification  that  omits  all  implementation  details. 


Trap  Door 

A  hidden  software  or  hardware  mechanism  that  can  be  triggered  to  permit 
system  protection  mechanisms  to  be  circumvented.  It  is  activated  in  some 
innocent-appearing  manner;  eg.,  a  special  "random"  key  sequence  at  a 
terminal.  Software  oevelopers  often  introduce  trap  doors  in  their  code  to 
enable  them  to  reenter  the  system  and  perform  certain  functions.  Also  called 
back  door. 

Trojan  Horse 

A  computer  program  with  an  apparently  or  actually  useful  function  that  con¬ 
tains  additional  (hidden)  functions  that  surreptitiously  exploit  the  legitimate 
authorizations  of  the  invoking  process  to  the  detriment  of  security  or  in¬ 
tegrity. 

Trusted  Computer  System 

A  system  that  employs  sufficient  hardware  and  software  assurance  measures 
to  allow  its  use  for  processing  simultaneously  a  range  of  sensitive  or  classified 
information. 

Trusted  Computing  Base  (TCB) 

The  totality  of  protection  mechanisms  within  a  computer  system  -  including 
hardware,  firmware,  and  software  -  the  combination  of  which  is  responsible 
for  enforcing  a  security  policy.  A  TCB  consists  of  one  or  more  components  that 
together  enforce  a  unified  security  policy  over  a  product  or  system.  The  ability 
of  a  TCB  to  enforce  correctly  a  unified  security  policy  depends  solely  on  the 
mechanisms  within  the  TCB  and  on  the  correct  input  by  system  administrative 
personnel  of  parameters  (e.g.,  a  user's  clearance  level)  related  to  the  security 
policy. 

Trusted  Path 

A  mechanism  by  which  a  person  at  a  terminal  can  communicate  directly  with 
the  Trusted  Computing  Base.  This  mechanism  can  only  be  activated  by  the 
person  or  the  Trusted  Computing  Base  and  cannot  be  imitated  by  untrusted 
software. 
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User 


Person  or  process  accessing  an  AIS  either  by  direct  connections  (i.e.,  via  ter¬ 
minals),  or  indirect  connections  (i.e.,  prepare  input  data  or  receive  output  that 
is  not  reviewed  for  content  or  classification  by  a  responsible  individual). 

Verification 

The  process  of  comparing  two  levels  of  system  specification  for  proper 
correspondence  (e.g.,  security  policy  model  with  top-level  specification,  top- 
level  specification  with  source  code,  or  source  code  with  object  code).  This 
process  may  or  may  not  be  automated. 


Virus 

A  self-propagating  Trojan  horse,  composed  of  a  mission  component,  a  trigger 
component,  and  a  self-propagating  component. 

Vulnerability 

A  weakness  in  system  security  procedures,  system  design,  implementation, 
internal  controls,  etc.,  that  could  be  exploited  to  violate  system  security  policy. 


Write 

A  fundamental  operation  that  results  only  in  the  flow  of  information  from  a 
subject  to  an  object. 

Write  Access  (Write  Privilege) 

Permission  to  write  an  object. 
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